1. Field of the Invention
The present invention relates to a communication system and a server which allow terminals located behind NAT routers, respectively, connected to a wide-area communication network such as Internet to communicate directly with each other.
2. Description of the Related Art
Conventionally, there are known network session systems that enable musical sessions such as ensemble performance of musical instruments and chorus such as duet through a wide-area communication network such as Internet. The session systems are designed such that performance information based on musical performance played on a terminal is transmitted to a different terminal via a wide-area communication network, and vice versa so that both the terminals can generate musical tones played by the terminals. In a case where the terminals are located behind NAT (Network Address Translation) routers (on the local side), respectively, however, it is necessary for the terminals to traverse the NAT routers in order to directly exchange performance information between the terminals without a server.
The NAT technology is described in “RFC 4787” in “http://www.ietf.org/rfc/rfc4787.txt”. The RFC 4787 is specifications disclosed by IETF (Internet Engineering Task Force) to explain NAT properties related to NAT traversal on unicast UDP. As behaviors of NAT routers, three patterns of Endpoint-Independent Mapping, Address-Dependent Mapping, and Address and Port-Dependent Mapping are commonly well known. Hereafter, these three behavior patterns of NAT routers will be explained. FIGS. 1A to 1D illustrate behavior patterns and issues of NAT routers. More specifically, in a case where source terminals such as PC (personal computers) located behind the respective NAT routers transmit packets by use of the same combination “source address: 192.168.0.1, source port number: 5000”, the source address and source port are to be translated by the NAT routers of the three different patterns as indicated in FIGS. 1A to 1C.
“Pattern <1>” of FIG. 1A indicates the behavior of a NAT router of a type which conducts the same port translation for any destination address and destination port for transmission from a terminal located behind the NAT router by use of the same combination of a source address and a source port number. This pattern is defined as “Endpoint-Independent Mapping” by RFC 4787. In this pattern <1>, the same combination of “source address: 192.168.0.1, source port number: 5000” is used in both the upper and lower cases. In the upper case, “destination address: 2.2.2.2, destination port 20000” is sent, while in the lower case, “destination address: 3.3.3.3, destination port 40000” is sent. Despite the different destinations between the cases, the NAT router conducts the same port translation for the two cases because of the same source address and port. In both cases, therefore, the NAT router translates the source address and port into “source address 1.1.1.1, source port 10000”, for example.
“Pattern <2>” of FIG. 1B indicates the behavior of a NAT router of a type which conducts different translations for different destination addresses in spite of transmission from a terminal located behind the NAT router by use of the same combination of the source address and the source port number, so that the translated source port numbers are sequential numbers (“1” is added to a previous translation result). This pattern is defined as “Address-Dependent Mapping” by RFC 4787. In this pattern <2>, the same combination of “source address: 192.168.0.1, source port number: 5000” is used in both cases. In the upper case, however, “destination address: 2.2.2.2, destination port: 20000” is sent, while in the lower case, “destination address: 3.3.3.3, destination port: 40000” is sent. In this pattern, the NAT router conducts different port translations between the cases because of different destinations despite the same source address and port. In the upper case, for example, the NAT router translates the source address and source port into “source address: 1.1.1.1, source port: 10000”. In the lower case, the NAT router adds “1” to the previous translation result so that the source address and source port can be translated into “source address: 1.1.1.1, source port: 10001”.
“Pattern <3>” of FIG. 1C indicates the behavior of a NAT router of a type which conducts different translations for the same destination address with different destination port numbers for transmission from a terminal located behind the NAT router by use of the same combination of the source address and the source port number, so that the translated source port numbers are sequential numbers (“1” is added to a previous translation result). This pattern is defined as “Address and Port-Dependent Mapping” by RFC 4787. In this pattern <3>, the same combination of “source address: 192.168.0.1, source port number: 5000” is used in both cases. In the upper case, however, “destination address: 2.2.2.2, destination port: 20000” is sent, while in the lower case, “destination address: 2.2.2.2, destination port: 30000” is sent. In this pattern, the NAT router conducts different port translations between the cases because of different destination ports despite the same destination address. In the upper case, for example, the NAT router translates the source address and source port into “source address: 1.1.1.1, source port: 10000”. In the lower case, the NAT router adds “1” to the previous translation result so that the source address and source port can be translated into “source address: 1.1.1.1, source port: 10001”.
In spite of attempts to realize direct communication between the two terminals located behind different NAT routers, the connection between the two terminals cannot be established due to the above-described influence of translation of source address and source port number by the respective NAT routers unless the respective terminals can be informed of their respective partner's translated port number and address by any manner.
For example, assume that a terminal PC 1 located behind the NAT router 1 and a terminal PC 2 located behind the NAT router 2 which know their respective partner's external (global) IP addresses: 3.3.3.3; 1.1.1.1 try to communicate with each other on the 5000th port. As indicated in FIG. 1D, more specifically, using the same combination of “source address: 192.168.0.1, source port number: 5000”, the PC 1 transmits “destination address: 3.3.3.3, destination port: 5000”, while the PC 2 transmits “destination address: 1.1.1.1, destination port: 5000”. However, their respective source port numbers: 20000, 30000 translated by the NAT router 1 and the NAT router 2, respectively, do not agree with the destination port number: 5000 of the NAT router 2 and the NAT router 1, failing to traverse the NAT routers 2 and 1.
In such a case, communication is possible in the pattern <1> and the pattern <2> by using a technique generally known as “UDP hole punching”. For example, a server located somewhere which is not behind any NAT is provided, so that the PC 1 and the PC 2 communicate with the server through the NAT router 1 and the NAT router 2, respectively, to allow the server to know the PCs' addresses and port numbers translated by the NAT routers 1 and 2. Then, the server informs the PC 1 that the address of PC 2 is 3.3.3.3, and the translated port number of PC 2 is 30000, and informs the PC 2 that the address of PC 1 is 1.1.1.1, and the translated port number of PC 1 is 20000. In a case where the NAT routers 1 and 2 are routers of pattern <1>, the PC 1 and the PC 2 transmit packets destined for the PC 1's address and port number and the PC 2's address and port number informed by the server, respectively, so that the packets can traverse the NAT routers. In FIG. 1D, although the PC 1 and the PC 2 have the same address “192.168.0.1” which is a local address, the local address of the PC 1 and the PC 2 may be either the same or different. In the other figures as well, furthermore, the local address may be either the same or different.
In a case where the NAT routers 1 and 2 are routers of pattern <2>, packets cannot traverse even if port numbers informed by the server are used. In many cases, however, source port numbers translated by the NAT router are sequential such as “30000”—“30001”. Therefore, packets can traverse the NAT routers by sequentially trying previous and following port numbers such as port scanning. In the above-described example, if “30000” is unavailable, the PC 1 tries “30001” to traverse the NAT router. If “20000” is unavailable, the PC 2 tries “20001” to traverse the NAT router. In the pattern <2>, in other words, the source port number of packets will not change if the packets have the same destination address despite different destination port numbers as described below. Therefore, as long as the packets are destined for the same destination address, a combination that can traverse the NAT router can be found out by trying previous and following port numbers.
(PC 1 side) source port translated by NATdestination port20001→3000020001→30001 ⊚20001→30002. . .. . .(PC 2 side) source port translated by NATdestination port30001→2000030001→20001 ⊚30001→20002. . .. . .
By using the UDP hole punching technique, as described above, communication by use of the NAT routers of the pattern <1> shown in FIG. 1A and the pattern <2> shown in FIG. 1B is available. In a case, however, where both the NAT routers 1 and 2 are pattern <3> of FIG. 1C, in other words, in a case of the NAT router which conducts different source port translations for packets having the same source address, source port number, and destination address but different destination port numbers, the UDP hole punching technique cannot cope with such type of NAT routers. Even if previous and following port numbers are tried sequentially as in the case of pattern <2>, more specifically, the NAT router only changes translated source port number at each try. As a result, there will be no match that allows traverse. If either of the NAT 1 or 2 is pattern <1> or <2>, communication is available by using the UDP hole punching technique, for source port numbers translated by the NAT router of pattern <1> or <2> will not be changed.
(PC 1 side) source port translated by NATdestination port20001→3000020002→3000120003→3000220004→30003. . .. . .(PC 2 side) source port translated by NATdestination port30001→2000030002→2000130003→2000230004→20003. . .. . .